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(57) Abstract 

A cryptographic system (100) and method for encrypting and decrypting data using public key cryptography. The encryption and 
decryption (115) may be divided into tasks that may operate in parallel. A secure method of initializing the cryptographic system to allow 
for secure operations and protect against tampering with application software. The application program is retrieved from an encrypted file 
in external memory (124) and authenticated before being executed. 
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CRYPTOGRAPHIC SYSTEM 

BACKGROUND OF THE INVENTION 

This invention relates generally to communicating 
data securely, and more particularly to a cryptographic system 
and methods of using public key cryptography. 

Computer systems are found today in virtually every 
walk of life for storing, maintaining, and transferring 
various types of data. The integrity of large portions of 
this data, especially that portion relating to financial 
transactions, is vital to the health and survival of many 
commercial enterprises. Individual consumers also have an 
increasing stake in data security as open and unsecure data 
communications channels for sales transactions, such as credit 
card transactions over the Internet, gain popularity. 

Protecting data stored in computer memory, tape, and 
disk is often important. However, just as important, if not 
more so, is the ability to transfer financial transactions or 
other communications from a sender to an intended receiver 
without intermediate parties being able to interpret the 
transferred message. Furthermore, as important transactions 
are increasingly handled electronically, authentication of the 
originator of a message must be ensured. For example, for 
electronic banking, there needs to be a way to authenticate 
that an electronic document, such as a bank draft, has 
actually been "signed" by the indicated signatory. 

Cryptography, especially public key cryptography, 
has proven to be an effective and convenient technique of 
enhancing data privacy and authentication. Data to be 
secured, called plaintext, is transformed into encrypted data, 
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or ciphertext by a predetermined encryption process of one 
type or another. The reverse process, transforming ciphertext 
into plaintext, is termed decryption. in public key 
cryptography, the processes of encryption and decryption are 
controlled by a pair of related cryptographic keys. A 
"public" key is used for the encryption process, and a 
"private- key is used to decrypt ciphertext. Alternatively, 
the private key may be used to encrypt the data, and the 
public key to decrypt it. This latter method provides a 
method of digitally signing data to positively identify the 
source of the data. 

The prior art includes a number of public key 
schemes. However, over the past decade, one system of public 
key cryptography has gained popularity. Known generally as 
the " RSA " scheme, it is now thought by many to be a worldwide 
defacto standard for public key cryptography. The RSA scheme 
is described in U.S. Patent No. 4,405,829. 

The RSA scheme capitalizes on the relative ease of 
creating a composite number from the product of two prime 
numbers whereas the attempt to factor the composite number 
into its constituent primes is difficult. Pairs of 
public/private keys can then be found based on the factors of 
the composite number. A message is encrypted using a series 
of mathematical exponentiations and divisions based on one of 
25 the keys. If the matching key of the public /private key pair 
is known, the message can be decrypted using a series of 
mathematical exponentiations and divisions using the matching 
key. The composite number is a part of the public and private 
keys so it is known to the public. However, since the private 
key can only be found by factoring the composite number, 
calculating the private key from the public key is. 
computationally difficult. 

The security of the RSA technique can be enhanced by 
increasing the difficulty of factoring the composite number 
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through judicious choices of the prime numbers. (This, of 
course would be true for any encryption/decryption scheme 
using or requiring prime numbers.) Another, and principle 
enhancement, is to increase the length (i.e., size) of the 
composite number. Today, it is common to find RSA schemes 
being proposed in which the composite number is on the order 
of 6 00 digits long. The task of exponentiating a number this 
long, however, can be daunting and time consuming, although 
not as difficult as factoring. Therefore, increasing the 
length of the composite number increases the security, but 
only at the expense of increased time to perform the 
encryption and decryption. 

However, recently discovered techniques have greatly 
improved the efficiency with which encryption/decryption 
functions are performed using the RSA scheme. Rather than 
using two prime numbers to form the composite number 
conventionally employed in RSA cryptographic operations, it 
has been found that more than two prime numbers can also be 
used. In addition, it has also been found that the Chinese 
Remainder Theorem can be used to break an RSA encryption or 
decryption task into smaller parts that can be performed much 
faster than before. 

The Chinese Remainder Theorem allows the necessary 
computations to be divided into two exponentiations. Commonly 
assigned U.S. Pat. Appl . No. 08/784,453, filed January 16, 
1997, which is incorporated by reference for all purposes, 
discloses a method of using multiple prime numbers to create 
the composite number and further dividing the exponentiations 
into multiple smaller exponentiations. However, though the 
encrypting and decrypting exponentiations are smaller and 
therefore more quickly accomplished, the factorization of the 
composite number is no easier to compute. So, the security of 
the system is not compromised. 
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In addition to the security of . the data, another 
important issue with regard to cryptographic systems is the 
security of the system itself. in a system implementing an 
encryption algorithm, ensuring that the system is secure from 
tampering is important. One area of concern is the secure 
loading and storing of application programs for the system. 
If the application program can be altered or substituted, the 
security of a system may be breeched. 

It is therefore desirable to provide an efficient 
cryptographic system for implementing public key cryptography 
with multiple prime factors. It is also desirable to provide 
a cryptographic system that may be initialized to a secure 
state while providing maximum flexibility for the user in 
providing application programs to the system. 



SUMMARY OF THE INVENTION 

A cryptographic system is provided having a 
processor and a plurality of exponentiation units. The 
processor receives encryption or decryption requests from a 

2 0 host processor and divides them into one or more 

exponentiation tasks. These exponentiation tasks are 
transferred to one or more execution units that perform the 
exponentiation and return a value to the processor. This 
allows the exponentiations tasks to be performed in parallel, 
thereby decreasing the time needed to perform the encryption 
and decryption requests. 

The present invention further provides a method of 
initializing the cryptographic system in a secure manner. An 
external memory holds a first program file along with header 

3 0 information, a hash value, and a digital signature in an 

encrypted program packet. The first program file contains a 
key/option table holding an RSA cryptographic public key. A 
processor loads the encrypted program packet and decrypts it 
using a cryptographic key, however the resulting program file 
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is only executed by the processor after authenticating it. If 
it cannot be authenticated, then the cryptographic keys are 
zeroed out, and the cryptographic system is put into a non- 
functioning state . 

The first program file is authenticated by checking 
the header for proper format, computing an expected hash value 
of the first program file and comparing it with the hash 
value, and checking the digital signature with an RSA public 
key that is stored in the cryptographic system. 

After authenticating this first program file, the 
processor executes the first program file. The first program 
file loads a second program file from the external memory. 
This second program file is generally a user-application 
program. It is authenticated in a similar manner to the first 
program file, but the digital signature is checked against the 
RSA public key found in the key/option table. 

By this initialization process, the user of the 
cryptographic system may load personalized application 
programs with secret cryptographic keys not known to anyone 
else. The process ensures that the application programs 
cannot be altered or substituted with fraudulent programs. At 
the same time, the manufacturer of the cryptographic system 
can securely provide maintenance and upgrade programs over 
public networks, and ensure that only properly licensed users 
are using the programs. 

A further understanding of the nature and advantages 
of the inventions presented herein may be realized by 
reference to the remaining portions of the specification and 
the attached claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows, in block diagram form, a cryptographic 

system; 

Fig. 2 illustrates the cryptographic processor 
forming a part of the cryptographic system of Fig. 1; 

Fig. 3 illustrates, in block diagram form, the 
cryptographic coprocessor; 

Fig. 4 is a flow diagram of a secure startup program 
used to initialize the cryptographic system of Fig. 1; 

Fig. 5 shows a possible structure of a cyphertext 
program packet; and 

Fig. 6 is a flow diagram of a secondary loader 
program that may be used to load user applications. 

15 DESCRIPTION OF THE SPECIFIC EMBODIMENT 

Turning now to the figures, and for the moment, Fig. 
I, there is illustrated a cryptographic system 100 constructed 
according to the teachings of the present invention to 
implement RSA public key cryptography although, as will be 
20 evident to those skilled in this, art, other cryptographic 
schemes may be used. In operation, data is brought into 
cryptographic system 100 from an external source (not shown) 
such as a host computer, a network, or other source. The 
external source is connected to cryptographic system 100 
25 through a connector 103. Cryptographic system 100 operates to 
receive data and instruction from the external source or host, 
to encrypt or decrypt the data, and return it to the host. 

Preferably, the communicating medium connecting the 
host (not shown) and the cryptographic system 100 is a 
peripheral component interconnect (PCI) bus because, among 
other things, of its processor independence. However, it will 
be evident to those skilled in this art that other bus 
structures may be used, and even preferred given different 
host environments . 
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The connector 103 is coupled to a pair of processing 
boards 107 by a host interface 105. The processing boards 107 
are each substantially identical in design and construction, 
so that a description of one will apply equally to the other. 
Each processing board 107 is separately addressable and may 
operate in parallel with the other. 

As Fig. 1 shows, the processing boards 107 include a 
cryptographic processor 110 that operates, in response to the 
instructions from the host (not shown) , to perform encryption 
or decryption. To accelerate the exponentiation tasks 
requested of the cryptographic processor 110, one or more 
cryptographic co-processors 115 and a reconf igurable co- 
processor 117 are provided. The cryptographic co-processors 
115 are specially constructed to perform, quickly, the various 
exponentiations necessary to most cryptographic tasks. The 
cryptographic co-processors 115 are described in greater 
detail below in connection with Fig. 3. 

Data is transferred between cryptographic processor 
110 and cryptographic coprocessor (s) 115, and reconf igurable 
coprocessor 117 by a secure bus 120. Secure bus 120 carries 
address, control and data lines -- as well as any chip select 
lines that may be used. To preserve the security of the 
cryptographic system 100, all information of a secure nature 
is encrypted before being placed on secure bus 12 0. In the 
specific embodiment, a DES engine, capable of DES encryption 
and decryption, is included in cryptographic processor 110, 
cryptographic coprocessor (s) 115, and reconf igurable 
coprocessor 117 for providing the encryption and description 
for secure bus 120. Of course, other types of security, other 
than DES may be provided, depending upon how much security is 
required and the resources available to provide the security. 

Although the cryptographic processor 110, as will be 
seen, is constructed to include memory, additional memory, 
external to the cryptographic processor 110, is provided in 
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the form of a flash memory 124 and a random access memory 
(RAM) 12 6. Data is transferable to flash memory 124 and a 
random access memory (RAM) 126 by way of secure bus 120. In 
the specific embodiment, flash memory 124 has two megabytes of 
storage capacity. Its primary use in the specific embodiment 
is as a repository for a user-application program. A user- 
application program is encrypted and stored in flash memory 
124 along with information to protect it from unknown 
alteration. After the system is successfully booted and the 
user-application program loaded into cryptographic processor 
110, tests are done to ensure its authenticity before control 
of the system is transferred to the user-application program. 
Details of an exemplary method of securely booting the system 
and loading an application program are presented below with 
respect to Figs. 4 and 6. 

The RAM 126 is used for the storage of both secure 
and unsecure data. In the specific embodiment, it is one 
megabyte of volatile memory. 

Cryptographic processor 110 is provided with the 
output of crystal oscillator 155. from which it generates clock 
signals for its own use and for use by other components of 
cryptographic system 100. A battery 162 is also optionally 
provided to supply backup power during a power failure. its 
use is not required by the present invention. 

Fig. 2 depicts a more detailed description of 
cryptographic processor 110. Preferably, cryptographic 
processor 110 is physically secure from inspection and 
tampering by outside sources. In the specific embodiment, it 
meets the Federal Information Protection System (FIPS) level 3 
standard. A currently available cryptographic processor 110 
is the VMS310 - NetArmor™ Encryption Processor available from 
VLSI Technology, Inc., in San Jose, California. 

As Fig. 2 shows, the cryptographic processor 110 
includes a central processor unit (CPU) 210 as the main 



WO 99/39475 PCT/US99/02323 

9 

controller of the system. CPU 210 executes initialization 
sequences and user-application programs. It receives data and 
instructions from the external host and breaks the 
instructions down into tasks as required or necessitated by 
the user-application program. It assigns some of the tasks to 
other specialized units (e.g., the one or more cryptographic 
co-processors 115) as will be described below. In the 
specific embodiment, CPU 210 is a 32 -bit Advanced RISC Machine 
(ARM) 7 processor. This is a RISC-based processor constructed 
for pipeline operation. However, many different processors 
will be appropriate for use in a similar system. 

CPU 210 is coupled with other elements within 
cryptographic processor 110 by means of a data/address bus 
215. Data/address bus 215 is also coupled to host interface 
105 through a bus interface 217. Bus interface 217 provides a 
path to host interface 10 5, while keeping data/address bus 215 
secure from unwanted monitoring. Encryption and decryption 
requests are delivered to CPU 210 over data/address bus 215 
through bus interface 217, and the results are returned by the 
same path. In the specific embodiment, data/address bus 215 
is a 32 -bit data bus with control and address signals. Data 
on data/address bus 215 is not necessarily encrypted, but is 
kept secure from tampering with physical security that is 
built into the chip that prevents probing of the chip. 

During its operation, CPU 210 may have its operation 
interrupted by certain events. An interrupt circuit 225 is 
provided for sensing an interrupt event and communicating the 
event to CPU 210. This is a common practice and a design for 
interrupt circuit 225 will be readily apparent to one of skill 
in the art . 

As Fig 2. shows, the cryptographic processor 110 
incorporates various support devices, including random access 
memory and read-only (RAM 23 0 and ROM 24 0) , an 
encryption/decryption engine (DES engine 250) for encrypting 
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and decrypting information communicated on the secure bus 12 0, 
an exponentiator circuit 260, and hashing engine 270. These 
components are all communicated to CPU 210 by data/address bus 
215. 

The random access memory (RAM) 23 0 is provided as 
memory for use by CPU 210. In the specific embodiment, it is 
a two-kilobyte RAM with a 32-bit data input. It may be used 
for storing the user-application program upon which CPU 210 
operates , and as a scratchpad memory for temporary storage of 
data and variables. It is coupled to CPU 210 by data bus 215. 

ROM 24 0 is what is known as a volatile ROM or VROM; 
it is a read-only memory that is physically secure from 
tampering or probing. A purpose of ROM 24 0 is as a repository, 
for startup software which is installed in the factory and may 
not be altered. The startup software in ROM 240 is executed 
automatically by CPU 210 when power is applied to the system. 
This allows the system to initialize itself securely. 
Additional details of the startup software will be provided 
with respect to Fig. 4 below. 

A device select decoder 244 operates to decode 
certain address ranges and provides signals to select certain 
external devices. Though not a necessary element of the 
present invention, device select decoder 244 reduces the 
amount of logic needed on external devices to decode addresses 
and to add flexibility to external devices. In the specific 
embodiment, device select lines are used to enable individual 
cryptographic coprocessors 115. 

In the specific embodiment, secure bus 120 (Fig. 1) 
is connected to a secure memory management unit (MMU) forming 
a part of the CPU 210. Of course, if another device is used 
as CPU 210 that does not have a secure MMU, additional 
circuitry outside CPU 210 may be used to provide secure bus 
120. However, the MMU of CPU 210 operates to effectively 
shield the internal data bus 215 from external probing, 
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thereby securing internal information of the cryptographic 
processor 110 from surreptitious inquiry. The cryptographic 
processor 110 connects to secure bus 120 by a secure bus 
interface 246. Secure bus interface 246 provides the driver 
5 and receiver circuits for the signal lines that make up the 
secure bus 12 0. 

Before being placed on secure bus 12 0, data is first 
encrypted to make it secure by the DES bus encryption engine 
250, using Data Encryption Standard, an American National 

10 Standards Institute (ANSI) approved standard for data 

encryption (ANSI X3.92). The DES engine 250 is configured to 
operate at 2 0 Mbytes per second and will operate in either ECB 
or CBC modes. Details of the DES protocol are well known in 
the art of cryptography and may be found, for example, in U.S. 

15 National Bureau of Standard, "Data Encryption Standard, 11 

Federal Processing Standard (FIPS) Publication 46, January 
1977. However, the present invention is not limited to DES 
protocol for secure bus 120. Other encryption algorithms, now 
known or yet to be developed, may also be used to make secure 

2 0 bus 12 0 secure. 

The keys for the DES encryption performed by the DES 
engine 250 are generated randomly and stored by CPU 210. As 
such, no human need ever know the DES keys. In the specific 
embodiment, these keys are stored in real time clock (RTC RAM) 

2 5 25 5 that has a small amount of RAM provided. RTC RAM 255 has 
an external battery 257. This protects the contents of RTC 
RAM 255 when power is removed from the system. 

The RSA engine 2 60 is a special purpose arithmetic 
unit designed and structured to perform fast modular 

30 exponentiation. In the specific embodiment, it performs 10 
exponentiations per second on a 1024 bit value. Its design 
and operation will be understood by one of skill in the art. 
If another encryption method besides RSA public key 
cryptography is provided by the system, other types of 
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arithmetic units may be provided along with or instead of RSA 
engine 2 60. 

In operation, the cryptographic system 100 (Fig. 1) 
will receive an encryption request or a decryption request 
5 from the host (not shown) via messages that connects the 

system to the host. The encryption request will include the 
message data to be encrypted and, perhaps, the encryption 
keys. Alternatively, the encryption keys may be kept in RAM 
126 (Fig. 1) or RAM 230 (Fig. 2) of the cryptographic 

10 processor 110. The decryption request will include the 
cyphertext and the decryption keys. The request and any 
accompanying keys, are passed to cryptographic processor 110 
of one of the processing boards 107 by the host interface 105. 

For public key RSA, the CPU 210 of the cryptographic 

15 processor 110 receiving the request will construct 

exponentiation tasks for execution by RSA engine 260 from the 
message data and the keys. RSA engine 260 performs 
exponentiations and returns the results to CPU 210. As 
described above, the encryption and decryption may be broken 

20 into one or more exponentiation tasks. These tasks can be 
performed in parallel to speed up the operation. The 
individual results of the exponentiation tasks are combined 
using the principles of the Chinese Remainder Theorem by CPU 
210 to form the result as described in the aforementioned 

25 patent application Ser. No. 08/085,993, which was previously 
incorporated by reference . 

To speed up performance of the exponentiation tasks, 
the work may be offloaded on secure bus 12 0 to cryptographic 
coprocessor 115. Typically, cryptographic coprocessor 115 is 

30 a specialized processor capable of performing multiple 

exponentiations or other cryptographic calculations at a 
greater rate. More details regarding cryptographic 
coprocessor 115 will be given with respect to Fig. 3 below. 
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The hashing engine 270 is provided as part of the 
cryptographic processor 110 to calculate an expected hash 
value for a message provided to it . The expected hash value 
is generally a checksum value used to verify that the message 
has not been altered. If the expected hash value matches a 
hash value that was generated earlier and appended to the 
message, then a degree of confidence is gained in the validity 
of the message. The amount of confidence is based upon the 
hash algorithm used. In the specific embodiment, hash engine 
270 performs a FIPS 180-1 compliant Secure Hash Algorithm 
(SHA-1.) SHA-1 produces a 16 0 -bit hash value. 

Hash values are appended to messages sent over 
secure bus 12 0. If the message changes en route, the hash 
value that is attached to the data will not match the expected 
hash value that is computed for the message at the other end,. 

Physical security circuits 280 are also incorporated 
in cryptographic processor 110 to monitor the battery level 
and the VCC level . The physical security circuits operate to 
detect voltage levels which tend to indicate that the chip is 
possibly being tampered with and. provide an alarm to CPU 210. 
Included in physical security circuits is a non-volatile VROM 
282. VROM 282 is a memory that is physically secure, and one- 
time programmable. It is programmed with a seed for 
generating DES keys, the public key of an RSA public/private 
key pair, and an ICF flag. The uses of these components will 
be explained below with respect to Fig. 4 

Fig. 3 depicts a more detailed block diagram of 
cryptographic coprocessor 115. Data is communicated between 
cryptographic coprocessor 115 and secure bus 120 through I/O 
pins 312 which connect to an I/O controller router 310 by a 
data bus 316 and a control bus 318. As described herein, 
cryptographic co-processors 115 are each on a separate VLSI 
components. However, if it resided on the same component as 
cryptographic processor 110, I/O pins 312 would not be 
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necessary. In the specific embodiment, data bus 316 is a 32- 
bits wide data bus. One of the signals on control bus 318 may 
be a device select signal. The device select signal is 
decoded from an address range that is assigned to a particular 
5 cryptographic coprocessor 115. This may be any range 

addressable by the addressing bandwidth of CPU 210. As 
mentioned above, cryptographic processor 110 may include 
device select decoder 244 (Fig. 2) for providing the device 
select signal . When an address in the defined range is 

10 referenced, the device select signal is asserted for the 
particular cryptographic coprocessor 115. 

As Fig 3 further shows, the I/O controller router 
310 of the cryptographic co-processor 115 is coupled by a 
data/control bus 320 to a DES cell 330 and a number of 

15 exponentiation cells 340. The DES cell 330 operates as a 

companion to the DES engine 250 of the cryptographic processor 
110 (Fig. 2) . In fact, it is designed in much the same way as 
the DES engine 25 0 to decrypt data received from the secure 
bus 120, and to encrypt data to be communicated to the 

20 cryptographic processor 110. The exponentiation cells 340 are 
substantially identical to one another, and are special 
purpose arithmetic units designed and structured to do fast 
exponentiation. In the specific embodiment, cryptographic co- 
processor 115 includes six exponentiation cells 340, although 

25 this number may be greater or fewer depending on the needs of 
the user and the capabilities of the technology. The specific 
embodiment of cryptographic processor 110 allows the 
attachment of up to eight cryptographic co-processors 115 to a 
single cryptographic processor 110. 

30 In operation, a cryptographic coprocessor 115 

receives tasks from the cryptographic processor 110 (i.e., the 
CPU 210) and returns results of such tasks. Data received by 
I/O controller router 310 is generally encrypted. If so, it 
is sent to the DES cell 330 for decryption before being routed 
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to an available exponentiation cell 340. . The exponentiation 
cell performs the exponentiation, and the results are 
encrypted by DES cell 33 0 and sent back to cryptographic 
processor 110. Typically, the exponentiation calculations 
will .take much more time than the DES encryption/decryption. 
Therefore, having only one engine encryption/decryption (i.e., 
DES cell 330) does not generally cause a bottleneck to the 
throughput. However, if needed, multiple DES cells 330 may be 
provided. 

Fig. 4 illustrates, in flowchart form, the 
initialization procedure 4 00 used to start up cryptographic 
system 10 0 upon reset, and to possibly place the cryptographic 
system 100 in a secure state. Typically, the method is 
implemented as a series of software instructions that reside 
in a system memory, i.e., ROM 240 (Fig. 2) . Whatever memory 
is used to contain the process that implements the 
initialization method shown in Fig. 4 should be a secure 
memory so that it cannot be altered after its manufacture. 
ROM 24 0 is an example of such a secure memory. At the time of 
manufacture, software instructions are hardwired into ROM 240. 
The contents may not be externally probed or altered without 
destruction, nor can the ROM 240 be read by external (to the 
cryptographic processor 110) sources. The MMU of the CPU 210 
operates to isolate and shield the data bus 215, and thereby 
the content of ROM 240, from surreptitious access. 

The software operates on a processor such as CPU 
210. CPU 210 is constructed or otherwise configured so that 
the software in ROM 24 0 is automatically executed after a 
system reset before any other software. A purpose of this 
feature is to place the system in a secure state, and perhaps 
to load a proper application program. This ensures that the 
user knows which program is executing, and that the system is 
properly secured before any sensitive data is allowed to be 
brought into the system. 
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Referring to Fig. 4, at step 402 a chip reset occurs 
because of system power-up or other system reset. In this 
step, CPU 210 performs a self -test on the system and 
initializes all of the volatile registers to known values. 

After initialization is completed, in step 404, CPU 
210 examines its registers to determine if it is in a secure 
state or an unsecure state. Initially, the system will be in 
an unsecure state. Only a system that was previously in a 
secure state before powering down or being reset will be 
initiated to the secure state upon chip reset. 

If in step 404, CPU 210 determines that it is in a 
secure state, in step 4 06 it generates its DES keys from seed 
values found in RTC RAM 255, VROM 282, and ROM 240. These 
keys are stored in volatile RAM, so they must be regenerated 
each time the system is initialized. After generating the 
keys, CPU 210 proceeds to step 410 in which it loads a black 
boot program from flash memory. The details of step 410 will 
be given more completely below. 

If CPU 210 finds that it is not in a secure state, 
it proceeds to step 412 in which it waits for a command from 
the host (not shown.) Some time later, since CPU does not 
have a program to execute, the host issues a command to load a 
program. CPU examines the command, and it determines whether 
the command is to load a secure program or a normal (i.e., 
non- secure) program. The process for executing non- secure 
programs is illustrated below with respect to steps 650-685. 

In order to execute a secure program, the system 
must be put into the secure state. In step 416, the 
cryptographic keys are generated from RTC RAM 255, VROM 284, 
and the ROM 24 0 as in step 406. Then, in step 42 0, the host 
loads a program file 510 (Fig. 5) to the cryptographic system 
100. In step 420, program file 510 is a Secure_Load program 
designed to securely load a program from the flash memory 124. 
The program file is encrypted inside an encrypted program 
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packet 500 (Fig. 5) because it comes from the host outside the 
secure portion of the cryptographic processor 110. The 
encrypted program packet 500, in addition to being encrypted, 
preferably includes other protection to ensure its 
authenticity . 

In step 424, the encrypted program packet is 
decrypted and verified for authenticity. In the specific 
embodiment, the decryption is accomplished by DES engine 250, 
The decrypted result, a program packet that includes the 
program file and additional header and trailer information, is 
preferably subjected to further checks before loading the 
Secure_JLoad program into the CPU memory. These checks are 
done using the header and trailer information, to gain a level 
of confidence that the program is the one that is intended to 
be run . 

Digressing for the moment, Fig. 5 depicts an example 
of a format for the encrypted program packet. Preferably, the 
encrypted form of the program packet is triple -DES encoded 
using CBC mode. As Fig. 5 shows, the encrypted program packet 
500 contains a program file 510 .(for execution by CPU 210) 
preceded by a header 520 and followed by a trailer 530. The 
header 520 contains information about the program packet 500 
such as the length of the program file and its starting 
address. The trailer 530 contains additional security 
information such as a hash value 540 and a digital signature 
550 . 

Returning to step 424 of Fig. 4, after the program 
packet 500 is decrypted by the DES engine 2 50, it is then 
examined to determine that the decrypted program file has a 
valid program length and starting address as specified by the 
(also decrypted) information of the header 520. Finding that 
the format is correct provides a level of confidence that the 
decryption was properly performed, and/or that the decrypted 
program file was that retrieved from the host, i.e., that 
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there has not been clandestine attempt to introduce a 
fraudulent program file that could operate to extract 
confidential information from the cryptographic processor 110. 

If the program packet format is not what is 
expected, the system will exit step 424 in favor of an abort 
mode at step 427. Here, to protect itself from unwanted 
intrusion, the cryptographic system 100 will erase all 
cryptographic keys (i.e., the keys in RTC RAM 255) in step 
427, and the cryptographic system 100 is then placed in a non- 
functioning state. It remains in this state, until the 
cryptographic system 100 is reset. Since the initialization 
program did not complete, nothing about the system can be 
assumed to be secure, so secret data should not be allowed. 

If the packet format is determined to be correct, 
however, hash value 540, a checksum developed from the 
original (plaintext) form of the program file 510 is checked 
against that developed by the hash engine 270 after 
decryption. If a hash of the program file matches hash value 
54 0, then a level of confidence that the program file has not 
changed may be inferred. 

If, however, the hash values do not match, the 
initialization is aborted by exiting to step 427 to erase the 
cryptographic keys, as described above. Cryptographic 
processor 110 is then moved into the non- functioning state. 

A match of hash values moves the initialization 
procedure to its final check where is checks digital signature 
550. Digital signature 550 is created by encrypting the hash 
value with a private key of an RSA public/private pair. The 
hash value 54 0 developed from the program file before 
encryption and stored in flash, memory 124 is itself encrypted 
by the RSA scheme, using the private key of the pair, before 
being added to the trailer 530 of the program packet as the 
signature 550. The VROM 282 is programmed with the public key 
of the pair when the cryptographic system is manufactured. 
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When the program packet is decrypted, and a hash value 
produced from the decrypted version of the program file 510 , 
the accompanying signature 550 is then decrypted using the 
public key retrieved from the VROM 282, and the decrypted 
result compared to the created hash value. A match furnishes 
an added confidence that the program packet 500, and in 
particular the program file 510 it contains, was indeed 
generated from a source that was intended. 

If, however, the digital signature is incorrect, 
i.e., the hash value created by the hash engine 270 does not 
match that resulting from the RSA decryption of the signature 
550, the initialization is aborted to the key erasure step of 
step 427, and the cryptographic system 100 placed in the non- 
functioning state 462. 

Recognizing that spurious errors may occur during 
transmission or checking of the encrypted program packet 500, 
rather than aborting to the non- functioning state immediately 
upon detection of a anomaly in the checking scheme, in the 
specific embodiment, CPU 210 makes three attempts to 
authenticate the program before .aborting to step 427. 

If the checks performed at step 4 24 show that the 
encrypted program file 510 is authentic, the Secure__Load file 
510 is assumed to be correct, and is then written to the RAM 
23 0. In step 430, the keys are zeroized and the state is set 
to the secure state. Then in step 43 5, control of the CPU 210 
(and thereby the cryptographic system 100) is transferred to 
now RAM-based Secure_Load program 510. 

Although the Secure_Load program may be changed from 
time to time, this method provides a level of confidence that 
the program file 510 has not been altered or replaced by a 
fraudulent program. This allows a great amount of 
flexibility, while still providing security. Furthermore, 
maintenance updates and program enhancements may be made by 
simply changing the program that is downloaded from the host. 
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If it is properly signed, any program may be loaded. Also, 
since the program is signed by the private key, but may be 
verified by the public key, the private key does not need to 
be stored anywhere on the system. 
5 After control of CPU 210 is transferred to the 

program file, which in this step is the Secure_Load program, 
step 410 (already mentioned above) loads a secondary loader 
program referred to as a black boot program from the Flash 
Memory 124. 

10 Digressing for the moment, the black boot program is 

a program that may be customized for each user, by allowing 
the user to put personalized RSA keys and set other options in 
a key/option table, these keys being unknown to anyone else. 
The manufacturer or other provider of the cryptographic system 

15 creates the black boot program, including an empty key/option 
table. This black boot program is provided to the end-user in 
object form (without header, hash, signature, hash of the 
key/option table, and the key/option table itself) . The end- 
user generates the key/option table and delivers a hash of the 

2 0 table to the manufacturer. The -manufacturer concatenates the 
hash to the black boot image, hashes and signs the resulting 
image with the private key corresponding to the public key 
stored in the VROM 2 82. The signature (combined with the 
header, hash, signature, hash of the key/option table, and the 

25 key option table itself) is returned to the end-user. The 

black boot program is downloaded into the flash memory 124 of 
cryptographic system 100 from the host in encrypted form, in 
the format shown in Fig. 5. 

The black boot program 1 s main function is to load 

30 other user-application programs into flash memory 124, or to 
start an application from flash memory 124 (if it is already 
there) . These user- application programs may be anything the 
user wants to run, and are encrypted using the format shown in 
Fig. 5 and signed using the private RSA key corresponding to a 
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public RSA key in the key/option table. Since the RSA key is 
unknown to anyone other than the user, including the 
manufacturer of the cryptographic system, the user can run any 
program and ensure privacy. 

Referring again to Fig. 4, in step 440, CPU 210 
determines if the black boot is -authentic using the same 
technique described above in step 424. If it is not 
authentic, then operation is aborted to step 427 and the keys 
are zeroized and the cryptographic system 100 is placed in a 
non- functioning state awaiting a reset. If it is authentic, 
then the black boot program is loaded into RAM, and control of 
CPU 210 is transferred to the black boot program. 

Fig. 6, illustrates in flow diagram format, an 
exemplary black boot program 600, In step 604, black boot 
program 600 calculates new DES keys from RTC RAM 255, VROM 
282, and ROM 240, since these were zeroized during step 430. 
Using these DES keys, data may be transferred over the secure 
bus 120. User applications, when stored in flash memory 124 
are DES encrypted according to the format shown in Fig. 5. 

In step 6 08, black boot program validates the 
key/option table. In step 612, if the key/option table is 
valid, then the execution continues with step 614. If not, 
then the execution is aborted to step 427, the keys are 
zeroized and the cryptographic system 100 enters a non- 
functioning state, waiting for a chip reset. 

In step 614, a decision is made on what mode the 
cryptographic system is operating in. The black boot program 
600 has two modes, start_up_immediate and wait_f or_command. 
If the system is in start_up_immediate mode, then at this 
point the "black boot program 600 branches to step 618. In 
step 618, the program in flash memory 124 is authenticated 
using the procedure described for step 424. If it fails three 
times, then the keys are erased and the cryptographic system 
100 is place in non- functioning mode. If it passes the 
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authentication step 618, then control of CPU 210 is 
transferred to the user application program. 

If the system is in wait_f or_ command mode, then the 
black boot program 500 branches to step 624 and it stays in 
5 that <step until a command is issued. The commands that may be 
issued are init_load (initialize the system to load a program 
into flash memory 124) , start_flash (execute the program in 
flash memory 124) , and load_flash (load the program into 
flash memory 124) . If the command is start_flash, then the 

10 black boot program 500 branches to step 618 and 62 0 to 

authenticate and execute the program in flash memory 124. as 
described above. Otherwise, an init_load command is issued. 

Upon receipt of the init_load command, the black 
boot program 5 00 checks the key/option table for the value of 

15 a challenge/response bit in step 628 . If it is set, then a 
challenge response procedure is executed in step 632. The 
challenge/response procedure involves host communication to 
determine that the host is authorized to load the application 
into flash. The black boot program 600 generates a random 

2 0 number known as ChallengelD. ChallengelD is hashed and sent 
to the host, which attaches its own hashed random number and 
digitally signs them both using a private key, corresponding 
to a public key in the key/options table. These are sent back 
to the CPU 210, which decrypts them with the private key. 

25 If the challenge response procedure fails, the black 

boot program 500 is aborted to step 42 7, the keys are zeroized 
and the cryptographic system is placed in a non- functioning 
state. Otherwise, the black boot program 500 branches to step 
63 6, where it waits for a command. If the command is a 

30 load_flash command, then the program is authenticated in step 
638. If it fails, the program aborts to step 427, and if it 
succeeds then the user-application program is stored in the 
DES encrypted format of Fig. 5 in flash memory 124. If it is 
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.a start__flash command, then the program in flash is executed, 
after authentication. 

The following is pseudocode that is appropriate for 
use as black boot program 500. 

bb_start : 

Send "abb^nitializing" status to the host 
calculate the DES_KEY from seeds 

validate K0T_hash 

if K0T_hash is invalid 

/*This a fatal error*/ 

clear all RTC RAM 

Send "abb_kot_hash_f ailed" status to the host 
wait for reset 
END /*KOT hash not verified*/ 

IF START_UP is set to start Flash image 

/*We drop here if START_UP option is set to immediate mode*/ 
start_f lash () /*There will be not return*/ 
/*The START_UP option is set to command mode*/ 
IF WAIT_FOR_COMMAND suboption is set 
main_loop : 

wait__f or_command ( ) : 

IF received START_FLASH command 

/*The host has to feed the correct sequence of 
INIT_LOAD, LOAD_FLASHs or rely on the image to be in 
Flash */ 

Send " abb_s t ar t i ng_f lash" 

start_f rom_f lash ( ) 
END 

IF received INIT__L0AD command 
IF CHALLANGE^RESPONSE is not set 
reset errcode 
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else errcode = challenge_response ( ). 
IF (errcode) 

clear application area in RTC RAM 

goto main__loop 
END 

/*The application is authorized to load Flash*/ 

Send H abb_proceed_load n to the host 
DO FOREVER 
wait_f or_command ( ) 

/*The host is responsible to issue START-FLASH and 
LOAD_FLASH* / 
/*in correct order*/ 
IF received START_ FLASH 
start_f lash () 
IF received LOAD__FLASH 

/*A11 addresses, sizes and other parameters are in the 
mailbox/ * load_block ( ) 
END /*DO FOREVER*/ 
END 
END 

/*The command was not recognized (it was none of 
START_FLASH , I NI T_LOAD * / goto main__loop 

END 

/*We drop here is START-UP option isn't set*/ 
start_flash() /*There will be no return */ 

procedure start_flash: 

check hash and signature 

IF any of these didn't check up to 3 times 
erase application area in RTC RAM 
send "abb_ef lash" status to the host 
goto main_loop 
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END 

extract entry_point out of the application header 
IF APPLICA TION__NAME option did not pass validation 
Send "abb_ename " to host 
erase application area in RTC RAM 
goto main_loop 

END 

/*Here we actually start the secure application*/ 
transfer control to the entry point 

END start_flash 

proc edur e 1 oad__f lash 

Send M abb_loading" to the host 

read and validate load parameters, translate addresses 
needed 

unenvelope the RAM block using ENVELOPING option 
encrypt the data with the precomputed DEC key 
transfer the encrypted block to Flash 

Challeng g /Pg sponge Procedure 

Message = (RandFill | | ChallengelD) 
Hash = SHA1 (Message) 

Signature = RSApriv (Hash) 
Response = Message | | Signature 

compute ChallengelD 

send ChallengelD (challenge) to the host 
receive the response and verify all fields 
IF error 

return E__MSG 
IF response. ChallengelD ! =ChallengeID 

return E_ID 

calculate hash of (RandFill | | ChallengelD) from response 
verify signature of the hash 
IF verification error 
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return E_SGN 
ELSE 

return E_OK 

It can easily be envisioned that using the 
principles of this invention, application programs may be 
distributed in a variety of ways and maintain a level of 
security. For example, files may be sent over networks, such 
as the Internet, where there is great opportunity for 
mischief, but the sender and receiver can have a great deal of 
confidence that the program that ends up running on the "system 
has not been altered or replaced. Furthermore, a seller of 
software for secure systems may ensure that all systems 
running its software are authorized users. 

Referring again to step 412, if the program to be 
executed is a normal program, then in step 450, CPU 210 
examines an ICF flag in the VROM 282. The ICF flag is set at 
the manufacturer, and is put in place to meet certain 
governmental regulations about exporting cryptographic 
systems. If the ICF flag is set., then no program is allowed 
to run that is not digitally signed, even in normal mode. 
This prevents unauthorized programs from running, as the U.S. 
Government will not allow export of certain cryptographic 
techniques If the ICF flag is not set, then any program may 
be run, even if it is not digitally signed, in normal mode. 

If the ICF flag is set, then the program must be 
authenticated just as it is in the secure mode. Steps 655-665 
are similar to steps 416 through 424 described above. 
However, the program file may be any program that has been 
properly authenticated. If it is authenticated, then in step 
470, control of CPU 210 is transferred to the program. If it 
is not authenticated, then the keys are zeroized and the 
cryptographic system enters a non- functional state in step 
427 . 
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If the ICF flag is not set, then the system simply 
loads default keys in step 475 and loads a program from the 
host in step 480. The program is checked to ensure that it is 
correct, but no digital signature is provided. If it is 
correct, then it is executed in step 470, and if not then the 
program aborts to step 427 as described above. 

Although specific embodiments of the present 
invention have been included herein, these are given by way of 
example only. The invention is not limited, except by the 
attached claims. One of skill in the art can readily envision 
variations and alternatives to the cited examples that do. not 
depart from the spirit of the present invention. Such 
variations and alternatives are anticipated by this invention. 
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1. A method for initializing a secure system, 

2 comprising: 

3 loading a first encrypted program packet into the 

4 system from an external memory; 

5 decrypting the first encrypted program packet with a 

6 first cryptographic key to provide a first program file and a 

7 first digital signature; 

8 authenticating the first digital signature; and 

9 when the first digital signature is authentic / 
10 executing the first program file. 

1 2. The method of claim l, further comprising: 

2 loading a second encrypted program packet into the 

3 system from the external memory; 

4 decrypting the second encrypted program packet to 

5 provide a second program file and a second digital signature; 

6 and 

7 authenticating the second digital signature using a 

8 second cryptographic key from the first program file. 

1 3. The method of claim 1, further comprising: 

2 when the first digital signature is not authentic, 

3 not executing the first program file, and erasing the first' 

4 cryptographic key from a volatile memory. 

1 4. The method of claim 1 wherein the encrypted 

2 program packet is DES encrypted. 

1 5. The method of claim 1 wherein the encrypted 

2 program packet is triple-DES encrypted using a CBC DES 

3 algorithm. 
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1 6. The method of claim 1 wherein the external 

2 memory is a flash memory. 

1 7. The method of claim 1 wherein the decrypting 

2 further provides a header and a hash value for the program 

3 file. 

1 8. The method of claim 7 wherein the first digital 

2 signature is an RSA encryption of the hash value. 

1 9. The method of claim 8 wherein the RSA 

2 encryption is accomplished using a private key of a 

3 public/private key pair. 

1 10. The method of claim 9 further comprising: 

2 providing a public key of the public/private key 

3 pair; 

4 decrypting the first digital signature with the 

5 public key to produce a decrypted digital signature value; and 

6 determining the program file is not authentic if the 

7 decrypted digital signature value is not equal to an expected 

8 value . 

1 11. The method of claim 10 wherein the expected 

2 value is the hash value. 

1 12 . The method of claim 7 wherein the hash value is 

2 produced using a FIPS 180-1 standard algorithm. 

1 13. The method of claim 7 further comprising: 

2 calculating an expected hash value for the program 

3 file; 

4 comparing the expected hash value with the hash 

5 value; and 
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determining the program file is not authentic if the 

expected hash value does not equal the hash value. 

14. The method. of claim 7, further comprising: 
examining the header; 

determining the program file is not authentic if the 
header is not an expected format. 

15. A method of initializing a secure system 
comprising: 

loading a first encrypted program packet into .the 
system from an external memory; 

decrypting the first encrypted program packet with a 
first cryptographic key to provide a first program file, a 
hash value, and a first digital signature ; 

determining the program file is not authentic if the 
header is not an expected format; 

calculating an expected hash value from the program 

file; 

determining the program file is not authentic if the 

expected hash value is not equal to the hash valued- 
decrypting the digital signature using an RSA public 

key to produce a decrypted digital signature valued- 
determining the program file is not authentic if the 

decrypted digital signature value does not equal the hash 

value; and 

when the program file is not authentic, then erasing 
the first cryptographic key, otherwise, executing the program 
file. 

16. The method of claim 15 wherein the hash value 
is produced using a FIPS 180-1 standard algorithm. 
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1 17. The method of claim 15 wherein the cyphertext 

2 program is triple DES encoded with a CBC DES algorithm. 

1 18 . A computer software product including 

2 executable code stored on a computer readable storage medium 

3 causing a processor to: 

4 load a first encrypted program packet into the 

5 system from an external memory ; 

6 decrypt the first encrypted program packet with a 

7 first cryptographic key to provide a first program file and a 

8 first digital signature; 

9 authenticate the first digital signature; and 

10 when the first digital signature is authentic, 

11 execute the first program file. 

1 19. The computer software product of claim 18 

2 wherein the storage medium is a secure non-volatile memory. 

1 20. The computer software product of claim 18 

2 wherein the processor operates the executable code after a 

3 system reset before running any other executable code. 

1 21. A cryptographic system comprising: 

2 a bus interface for transferring data between the 

3 cryptographic system and an external source; 

4 a processor, the processor receiving data from the 

5 bus interface, and dividing the data into a plurality of 

6 exponentiation tasks; and 

7 a plurality of exponentiation units, wherein the 

8 processor' transfers the exponentiation tasks to at least one 

9 of the plurality of exponentiation units, and the at least one 

10 of the plurality of exponentiation units return an 

11 exponentiation of the exponentiation units to the processor. 
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22. The cryptographic system of claim 21 wherein at 
least one of the plurality of exponentiation units is on a 
first integrated circuit and the processor is on a second 
integrated circuit . 

23. The cryptographic system of claim 22 further 
comprising : 

a first encryption engine on the first integrated 

circuit ; 

a second encryption engine on the second integrated 

circuit ; 

a secure bus, whereby when data is transferred from 
the first integrated circuit to the second integrated circuit, 
it is encrypted by the first encryption engine. 

24. The cryptographic system of claim 23 wherein 
the second encryption engine decrypts the data. 

25. A cryptographic system comprising: 

a memory unit, the memory unit containing encrypted 

data; 

a cryptographic processor device, the cryptographic 
processor device including: 

a processor; 

an encryption engine for decrypting encrypted 
data into decrypted data including a program file; 

hashing unit for determining a hash value of 
the program file; and 

a public key encryption engine for decrypting a 
digital signature in the decrypted data to produce a decrypted 
digital signature value; 

wherein upon a system reset, the processor retrieves 
the cyphertext data from the memory unit and selectively 
executes the program file. 
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1 26. The cryptographic system of claim 25 wherein 

2 the public key encryption engine performs RSA public key 

3 encryption using the public key of a public/private key pair 

4 for decrypting the digital signature. 

1 27. A secure digital system, comprising: 

2 a processor; 

3 an encryption unit residing on the same substrate as 

4 the processor, the encryption unit being coupled to the 

5 processor by a first data bus, the first data bus being* 

6 protected from external probing ; 

7 a destination unit, the destination unit not 

8 residing on the same substrate as the processor, the 

9 destination unit being coupled to the processor by a second 

10 data bus, wherein the processor directs data to the encryption 

11 unit on the first data bus to produce encrypted data, and the 

12 processor directs the encrypted data to the destination unit 

13 on the second data bus . 

1 28. The secure digital system of claim 27, further 

2 comprising 

3 a decryption unit, wherein the processor retrieves 

4 the encrypted data from the destination unit on the second 

5 data bus, and directs the encrypted data to the decrypting 

6 unit to reproduce the data. 

1 29. The secure digital system of claim 28, wherein 

2 the encryption unit and the decryption unit are a single unit. 
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30. The secure digital system of claim 27, wherein 
the encryption unit performs DES encryption. 
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1 31. The secure digital system of claim 27, wherein 

2 the destination unit is a memory. 

1 32. The secure digital system of claim 31, wherein 

2 the memory is one of the set consisting of random access 

3 memory and flash memory. 

1 33. The secure digital system of claim 27, wherein 

2 the destination unit is a co-processing unit. 

1 34. The secure digital system of claim 33, wherein 

2 the destination unit includes an encryption/decryption unit 
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for decrypting encrypted data received from the second data 
bus and for encrypting data for sending on the second data 



5 bus . 
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